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DHCPv6 Prefix Delegation in Long-Term Evolution (LTE) Networks 
Abstract 


As interest in IPv6 deployment in cellular networks increases, 
several migration issues have been being raised; IPv6 prefix 
management is the issue addressed in this document. Based on the 
idea that DHCPv6 servers can manage prefixes, we use DHCPv6 Prefix 
Delegation to address such prefix management issues as an access 
router offloading delegation of prefixes and release tasks to a 
DHCPv6 server. The access router first requests a prefix for an 
incoming mobile node from the DHCPv6 server. The access router may 
next do stateless or stateful address allocation to the mobile node, 
e.g., with a Router Advertisement or using DHCP. We also describe 
prefix management using Authentication, Authorization, and Accounting 
(AAA) servers. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This is a contribution to the RFC Series, independently of any other 
RFC stream. The RFC Editor has chosen to publish this document at 
its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by 
the RFC Editor are not a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6653. 
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document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
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1. Introduction 


Figure 1 illustrates the key elements of a typical cellular access 
network. In a Long-Term Evolution (LTE) network, the Access Router 
(AR) is the Packet Data Network (PDN) Gateway [3GPP-23401]. 


4+------------- + 
+------ + | 
DHCP 
+----- Aes PSS SS Ae hE S SSeS a oa + Server torta + 
MN |--| BS |--+Access+--+Access+-+ +------ + +-+Border| 
+----- + $----- + | cw | |Router| |IP Network(s)| |Router+-Internet 
+--+---+ +--+---+ | | +------ + 
| | 4+------------- + 
+----- + +----—- + | | +-----—- + 
MN |--| Bs |----- + | AAA 
+----- +e korras + +--- |Server 
+------ + 


Figure 1: Key Elements of a Typical Cellular Network 


The Mobile Node (MN) attaches to a Base Station (BS) through an LTE 
air interface. A BS manages connectivity of User Equipment (UE) and 
extends connections to an Access Gateway (GW), e.g., the Serving 
Gateway (S-GW) in an LTE network. The access GW and the AR are 
connected via an IP network. The AR is the first-hop router of the 
MNs and is in charge of address/prefix management. 


The AR is connected to an IP network that is owned by the operator; 
this network is connected to the public Internet via a border router. 
The network contains servers for subscriber management, including 
Quality of Service, billing, and accounting, as well as a Dynamic 
Host Configuration Protocol (DHCP) server [RFC6342]. 


With IPv6 addressing, because mobile network links are point-to-point 
(P2P), the per-MN interface prefix model is used [RFC3314] [RFC3316]. 
In the per-MN interface prefix model, prefix management is an issue. 


When an MN attaches to an AR, the AR requests one or more prefixes 
for the MN. When the MN detaches from the AR, the prefixes should be 
released. When the MN becomes idle, the AR should keep (i.e., not 
release) the allocated prefixes. 


This document describes how to use DHCPv6 Prefix Delegation 
(DHCPv6-PD) in mobile networks, such as networks based on standards 
developed by the 3rd Generation Partnership Project (3GPP) and it 
could easily be adopted by the Worldwide Interoperability for 
Microwave Access (WiMAX) Forum as well. In view of migration to 
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IPv6, the number of MNs connected to the network at a given time may 
become very high. Traditional techniques such as prefix pools are 
not scalable. In such cases, DHCPv6-PD becomes the viable approach 
to take. 
The techniques described in this document have not been approved by 
the IETF or the 3GPP, except for those techniques described below in 
Section 3.3. This document is not a Standard or Best Current 
Practice. This document is published only for possible consideration 
by operators. 
This document is useful when address space needs to be managed by 
DHCPv6-PD. There are obviously other means of managing address 
space, including having the AR track internally what address space is 
used by what mobile. 

2. Terminology and Acronyms 
3GPP - 3rd Generation Partnership Project 
AAA - Authentication, Authorization, and Accounting 
AR - Access Router 
BS - Base Station 
DHCP - Dynamic Host Configuration Protocol 
E-UTRAN - Evolved Universal Terrestrial Radio Access Network 
GPRS - General Packet Radio Service 
LTE - Long-Term Evolution 
MN - Mobile Node 
P2P - Point-to-Point 
PD - Prefix Delegation 
PDN - Packet Data Network 


S-GW - Serving Gateway 


WiMAX - Worldwide Interoperability for Microwave Access 
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3; 


3x 


Prefix Delegation Using DHCPv6 


"Access router" refers to the cellular network entity that has a DHCP 
client. According to [3GPP-23401], the DHCP client is located in the 
PDN Gateway, and so the AR is the PDN Gateway in the LTE 
architecture. 


1. Prefix Request Procedure for Stateless Address Configuration 


There are two function modules in the AR: the DHCP client and the 
DHCP relay. DHCP messages should be relayed if the AR and a DHCP 
server are not directly connected; otherwise, the DHCP relay function 
in the AR is not necessary. Figure 2 illustrates a scenario in which 
the AR and the DHCP server aren’t directly connected: 


+------- + | DHCP | Relay | +----------- + 


+ 


|1 Initial NW entry | 
or attach procedure 


| 
| 
| 
<----------------- > | 
| |2 Solicit | 
| | --------- > Relay-forward | 
| sie cre caets >| 
| | 3 Relay-reply | 
Advertise E 5-5-7 ------- 
< SS Se 
| |4 Request | 
| | --------- > Relay-forward | 
| i tare >| 
| | 5 Relay-reply | 
Reply SETE ee 
< SS 
|6 Attach | | 
| Completed | | 
ee >| | 
|7 Router | | 
| Solicitation | 
[ye eee foe ee een epee toy eee ane ey ei > 
| 8 Router | | 
| Advertisement | | 
pae aa | | 


Figure 2: Prefix Request 
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1. An MN (also referred to as UE, or User Equipment, by the 3GPP) 
performs initial network entry and authentication procedures, 
a.k.a. the attach procedure. 


2. On successful completion of Step 1, the AR initiates the DHCP 
Solicit procedure to request prefixes for the MN. The DHCP 
client in the AR creates and transmits a Solicit message as 
described in Sections 17.1.1 ("Creation of Solicit Messages") and 
17.1.2 ("Transmission of Solicit Messages") of [RFC3315]. The 
DHCP client in an AR that supports DHCPv6 Prefix Delegation 
[RFC3633] creates an Identity Association for Prefix Delegation 
(IA_PD) and assigns it an Identity Association IDentifier (IAID). 
The client must include the IA_PD option in the Solicit message. 
The DHCP client as Requesting Router (RR) must set the 
prefix-length field to a value less than, e.g., 48 or equal to 64 
to request a /64 prefix. Next, the relay agent in the AR sends 
to the DHCP server a Relay-forward message in which a Solicit 
message is encapsulated. 


3. The DHCP server sends an Advertise message to the AR in the same 
way as that described in Section 17.2.2 ("Creation and 
Transmission of Advertise Messages") of [RFC3315]. An Advertise 
message with the IA_PD shows that the DHCP server is capable of 
delegating prefixes. This message is received encapsulated in a 
Relay-reply message by the relay agent in the AR and is sent as 
an Advertise message to the DHCP client in the AR. 


4. The AR (DHCP client and relay agent) uses the same message 
exchanges as those described in Section 18 ("DHCP Client- 
Initiated Configuration Exchange") of [RFC3315] and in [RFC3633] 
to obtain or update prefixes from the DHCP server. The AR (DHCP 
client and relay agent) and the DHCP server use the IA_PD Prefix 
option to exchange information about prefixes in much the same 
way as IA Address options are used for assigned addresses. This 
is accomplished by the AR sending a DHCP Request message and the 
DHCP server sending a DHCP Reply message. 


5. The AR stores the prefix information it received in the Reply 
message. 


6. A connection between the MN and AR is established, and the link 
becomes active. This step completes the Packet Data Protocol 
(PDP) Context Activation Procedure in Universal Mobile 
Telecommunications System (UMTS) and PDN connection establishment 
in LTE networks. 
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7. The MN may send a Router Solicitation message to solicit the AR 
to send a Router Advertisement (RA) message. 


8. The AR advertises the prefixes received in the IA_PD option to 
the MN via an RA once the PDP Context/PDN connection is 
established, or in response to a Router Solicitation message sent 
from the MN. 


The 4-way exchange between the AR as RR and the DHCP server as 
Delegating Router (DR), as shown in Figure 2, may be reduced to a 


two-message exchange by using the Rapid Commit option [RFC3315]. The 
DHCP client in the AR acting as RR includes a Rapid Commit option in 
the Solicit message. The DR then sends a Reply message containing 


one or more prefixes. 
3.2. Prefix Request Procedure for Stateful Address Configuration 


Stateful address configuration requires a different architecture than 
that shown in Figure 2; in this type of configuration, there are two 
function modules in the AR: the DHCP server and the DHCP client. 


After the initial attach is completed, a connection to the AR is 
established for the MN. The DHCP client function at the AR as RR and 
the DHCP server as DR follow Steps 2 through 5 of the procedure shown 
in Figure 2 to get the new prefix for this interface of the MN from 
the IA_PD option exchange defined in [RFC3633]. 


The DHCPv6 client at the MN sends the DHCP Request to the AR. The 
DHCP server function at the AR must use the IA_PD option received in 
the DHCPv6-PD exchange to assign an address to the MN. The IA_PD 
option must contain the prefix. The AR sends to the MN a DHCP Reply 
message containing the IA address option (IAADDR). Figure 3 shows 
the message sequence. 


The MN configures its interface with the address assigned by the DHCP 
server in the DHCP Reply message. 
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In Figure 3, the AR may be the home gateway of a fixed network to 
which the MN gets connected during the MN’s handover. 


4+---------- + 4+-------------- + 4+----------- + 
| MN | | AR | DHCP Server 
| [DHCP | | DHCP |DHCP | +----------- + 
| |Client | |Server|Client | 
4+---------- + 4+-------------- + 


Initial NW entry 
or attach procedure 


ee >> l | 
| | DHCPv6-PD exchange | 
| | similar to Steps 2-5 | 
| Solicit | of Figure 2 (IA_PD) | 
SS Se ee a ee > 
Advertise 
ee | | 
| Request | | 
[remy a A >| | 
| | | 
| | | 
Use prefix in IA_PD 

| Reply | to assign IAADDR 
|<-------+------------- | | 


Figure 3: Stateful Address Configuration Following PD 
3.3. The MN as Requesting Router in Prefix Delegation 


The AR may use a DHCPv6 Prefix Delegation exchange to get a delegated 
prefix shorter than /64 by setting the prefix-length field to a value 
less than 64, e.g., 56 to get a /56 prefix. Each newly attaching MN 

first goes through the steps in Figure 2, in which the AR requests a 

shorter prefix to establish a default connection with the MN. 


The MN may next request additional prefixes (/64 or shorter) from the 
AR using DHCPv6 Prefix Delegation, where the MN is the RR and the AR 
is the DR (see [RFC6459] and Section 5.3.1.2.6 of [3GPP-23401]). In 
this case, the call flow is similar to that shown in Figure 3. The 
Solicit message must include the IA_PD option with the prefix-length 
field set to 64. The MN may request more than one /64 prefix. The 
AR as DR must delegate these prefixes, excluding the prefix assigned 
to the default connection. 
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3.4. Prefix Release Procedure 


Prefixes can be released in two ways: via prefix aging, or via the 
DHCP release procedure. In prefix aging, a prefix should not be used 
by an MN when the prefix ages, and the DHCP server can delegate it to 
another MN. A prefix lifetime is delivered from the DHCPv6 server to 
the MN via the DHCP IA_PD Prefix option [RFC3633] and the RA Prefix 


Information option [RFC4861]. Figure 4 illustrates how the AR 
releases prefixes to a DHCP server that isn’t directly connected to 
the AR: 


1. A signal that an MN has detached, such as switch-off or handover, 
triggers the prefix release procedure. 


2. The AR initiates a Release message to give the prefixes back to 
the DHCP server. 


3. The server responds with a Reply message. The prefixes can then 
be reused by other MNs. 


| | | 
| 1 De-registration | | 
| handover, or other | | 
| | | 


A 
l 
| 
| 
| 
l 
| 
| 
l 
| 
| 
| 
l 
l 
| 
l 
| 
| 
| 
| 


Figure 4: Prefix Release 
3.5. Miscellaneous Considerations 
3.5.1. How to Generate an IAID 
The IAID is 4 bytes in length and should be unique in the scope of an 
AR. The prefix table should be maintained; this table contains the 
IAID, the Media Access Control (MAC) address, and the prefix (es) 


assigned to the MN. In LTE networks, the International Mobile 
Equipment Identity (IMEI) uniquely identifies the MN’s interface and 
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thus corresponds to the MAC address. The MAC address of the 
interface should be stored in the prefix table and is used as the key 
for searching the table. 


The IAID should be set to Start_IAID; Start_IAID is an integer of 
4 octets. The following algorithm is used to generate the IAID: 


1. Set this IAID value in the IA_PD Prefix option. Request a prefix 
for this MN as described in Section 3.1 or Section 3.2. 


2. Store the IAID, MAC address, and received prefix(es) in the next 
entry of the prefix table. 


3. Increment the IAID. 


A prefix table entry for an MN that hands over to another AR must be 
removed. The IAID value is released and can then be reused. 


3.5.2. Policy to Delegate Prefixes 


In P2P links, if /64 prefixes of all MNs connected to one or more ARs 
are broadcast dynamically upstream as route information, high 
routing-protocol traffic (IGP, OSPF, etc.) due to per-MN interface 
prefixes will result. There are two solutions to this problem. One 
solution is to use static configuration, which would be preferable in 
many cases. No routing protocols are needed, because each AR has a 
known piece of address space. If the DHCP servers also know that 
address space, then they will assign to a particular AR a prefix from 
that space. 


The other solution is to use route aggregation. For example, each AR 
can be assigned a /48 or /32 prefix (an aggregate prefix, a.k.a 
service provider common prefix), while each interface of an MN can be 
assigned a /64 prefix. The /64 prefix is an extension of the /48 
prefix -- for example, an AR’s /48 prefix is 2001:db8:0::/48 -- while 
an interface of the MN is assigned a 2001:db8:0:2::/64 prefix. The 
border router in Figure 1 may be manually configured to broadcast 
only an individual AR’s /48 or /32 prefix information to the 
Internet. 


4. Prefix Delegation Using RADIUS and Diameter 


In the initial network entry procedure shown in Figure 2, the AR as 
Remote Authentication Dial In User Service (RADIUS) client sends an 
Access-—Request message with MN information to the RADIUS server. If 
the MN passes the authentication, the RADIUS server may send an 
Access-Accept message with prefix information to the AR using the 
Framed-IPv6-Prefix attribute. The AAA server also provides routing 
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information to be configured for the MN on the AR using the 
Framed-IPv6—-Route attribute. Using such a process, the AR can handle 
initial prefix assignments to MNs, but managing the lifetime of the 
prefixes is totally left to the AR. The Framed-IPv6-Prefix is not 


designed to support delegation of IPv6é prefixes. For this situation, 
the Delegated-IPv6-Prefix attribute, which is discussed below, can be 
used. 


[RFC4818] defines a RADIUS attribute, Delegated-IPv6-Prefix, which 
carries an IPv6é prefix to be delegated. This attribute is usable 
within either RADIUS or Diameter. [RFC4818] recommends that the DR 
use the AAA server to receive the prefixes to be delegated, by using 
the Delegated-IPv6-Prefix attribute/Attribute-Value Pair (AVP). 


The DHCP server as DR, as shown in Figure 2, may send an 
Access-Request packet containing the Delegated-IPv6é-Prefix attribute 
to the RADIUS server to request prefixes. In the Access—Request 
message, the DR may provide a hint that it would prefer a prefix -- 
for example, a /48 prefix. As the RADIUS server is not required to 


honor the hint, the server may delegate a longer prefix -- e.g., /56 
or /64 -- in an Access-Accept message containing the 
Delegated-IPv6-Prefix attribute [RFC4818]. The attribute can appear 


multiple times when the RADIUS server delegates multiple prefixes to 
the DR. The DR sends the prefixes to the RR using the IA_PD option, 
and the AR as RR uses them for MNs, as described in Section 3. 


When Diameter is used, the DHCP server as DR, as shown in Figure 2, 


sends an AA-Request message. The AA-Request message may contain a 
Delegated-IPv6-Prefix AVP. The Diameter server replies with an 
AA-Answer message. The AA-Answer message may contain a 


Delegated-IPv6-Prefix AVP. The AVP can appear multiple times when 
the Diameter server assigns multiple prefixes to an MN. The 
Delegated-IPv6—-Prefix AVP may appear in an AA-Request packet as a 
hint from the AR to the Diameter server that it would prefer a 

prefix -- for example, a /48 prefix. The Diameter server may 
delegate in the AA-Answer message a /64 prefix, which is an extension 
of the /48 prefix. As in the case of RADIUS, the DR sends the 
prefixes to the RR using the IA_PD option, and the AR as RR uses them 
for the MNs as described in Section 3. 


5. Security Considerations 


This document does not introduce any additional message types and 
therefore does not introduce any additional threats. The security 
procedures for DHCPv6 [RFC3633], RADIUS [RFC2865], and Diameter 
[RFC3588] apply. 
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